20180525 JaSST'18 Tohoku 「HAYST法」

ヘイスト！

https://gyazo.com/c8e23557693b688710b29ee92dba99c0

※7/8に何かやりたいです

↑実際にHAYST法を使ったラルフチャートやFV表をレビューする会 のイメージ

HAYST法誕生のきっかけ

誰も想定していなかった不具合が起きた

紙の厚さがXXである場合にプリントがうまくいかない

なぜ想定できないのか、想定外にどうやったら気づけるのか

市場規模のキワを見極めたい

組み合わせテストの難しさ

有則のテストは想定しやすい

無則のテストは想定しづらい　→要素Aと要素Bは、仕様上は無関係

無則の組み合わせテストをはじめるための前提条件3つ

仕様書がある(有則の組み合わせはテストできる)

単機能テストおよび有則の組み合わせテストは終わっている(できなくはないが、非効率)

単機能テストと同程度の工数を確保している

HAYST法が扱うもの、扱わないもの

扱う(≒組み合わせを考えたあとに変えてはいけないもの？)

アジャイル　ユーザーストーリーを用いて組み合わせを考える

仕様書　仕様書がなければテストをしている場合ではない

ユニットテスト これが一番大切

運用・保守　リリースして終わりではない　未来のことまでカバーする　未来スライダー

非機能要件　機能を目的の単位で取り扱うことで、いわゆる非機能要件もカバーする

扱わない(≒組み合わせを考えたあとに変えても構わないもの？)

商品企画　ビジネスの分析

要求　要求はあてにならない→仕様書が適切にできていれば要求は必要ない

ペルソナ　たくさんペルソナを書いたとしても、広大な市場範囲はカバーできない

内部構造　外部仕様に沿って動作する限り、アルゴリズムを変えても構わない

受け入れテスト　受け入れテストの役割は「業務に使えるかどうか」の確認であり、組み合わせを考えるところではない

コストと品質は正比例して上がってほしいが、実際には品質は思うように上がらない。

品質を維持してコストを減らし、費用対効果を理想のラインに近づける

ソフトウェア開発/テストを妨げる「5悪」をHAYST法で対策する

ソフトウェアが大規模・複雑化する　→6W2H、FV表

変化を予測しない、想定できない →3W、直交表

ソースコードを読まない、読めない　→ラルフチャート

テスト戦略なし、テストアーキテクチャなし　→D-Case

個人/組織ノウハウを蓄積しない　→FL表

HAYST法のプロセス

テストベース

テスト戦略　→D-Case

テスト要求分析　→6W2H、FV表

テスト設計　→ラルフチャート

因子・水準分析　→FL表

テスト実装

テスト実施

テスト結果分析

※基本的には下から適用するのがおすすめらしいです(まなべさん情報)

まずFL表→ラルフチャート、というイメージ